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[57] ABSTRACT 

A processing system and method receive batch payment data 
from a plurality of different sources, such as lock-boxes, an 
ATM or customer activated terminal, an enhanced 
telephone, a bank teller, or a personal computer. ITie batch 
payment data is converted into individual transaction data 
for on-line processing and is sent to a temporary payment 
queue. A transaction mover places the data from the queue 
to a u-ansaction queue and a transaction router subsequently 
assigns the transactions to available drivers. Each driver 
processes the payment data and makes appropriate account 
information updates to a set of master files. A transaction 
handler coordinates the control of the transaction mover as 
well as the control of the transaction router. The system 
operates in conjunction with on-line operations, such as 
customer service and other mortgage services, and has a 
transaction handler monitor which controls the speed of 
processing so that on-line operations can continue during the 
processing of the payment data. Since the updates to the 
master files to reflect the received payment data occur during 
normal operating hours and not at the end of the day, delays 
in updating account information can be significantly 
reduced. The speed control offered by the handler monitor 
enables the system and method to balance the processing of 
the received batch data with normal CICS activity. 

35 Claims, 12 Drawing Sheets 
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PROCESS FACILITY MANAGEMENT 
MATRIX AND SYSTEM AND METHOD FOR 
PERFORMING BATCH, PROCESSING IN AN 
ON-LINE ENVIRONMENT 

NOTICE OF COPYRIGHTED MATERIAL IN 
DISCLOSURE 

A portion of the disclosure of this patent document 
contains material that is subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduc- 
tion by anyone of the patent document or of the patent 
disclosure, as it appears in the Patent and Trademark OflSce 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

HELD OF THE INVENTION 

l^e invention generally relates to a transaction processing 
system and method and, more particularly, to a speed- 
controlled system and method for processing mortgage 
payments and other types of batch data in conjunction with 
other on-line processing. 

BACKGROUND OF THE INVENTION 

In a typical mortgage processing system, a branch faciUty, 
otherwise known as a lock-box, receives payments from the 
mortgagees or customers and performs an initial amount of 
processing on each payment. This processing includes the 
scanning of a payment coupon and an enclosed check and 
storing the data associated with each payment in batch form 
in a database. At the end of the day, the lock-box facility 
transmits the batch payment data to a central processing 
facility. A mortgage processing system may have a plurality 
of lock-boxes with each lock -box responsible for payments 
within a certain geographical region and each lock-box 
transmitting its batch payment data to the central facility at 
the end of the day. 

The central processing facility receives the payment data 
in batch form from the various lock-boxes and performs 
batch processing. More specifically, the central facility 
updates a set of master files by making appropriate changes 
to the principal, interest, and escrow for each account. The 
number of accounts updated in one day can easily approach 
twenty to thirty thousand, whereby the central facility 
expends an enormous amount of time performing the batch 
processing of the payment data. 

In addition to the batch processing of payment data, the 
central processing facility performs some additional func- 
tions. For instance, the central facility also provides normal 
users of the system with on-line access to account informa- 
tion in the master files. These users need to access the master 
files in real-time in order to provide customer services and 
to provide other types of mortgage services. Because the 
system provides these services to the various users in 
real-time, the central facility must perform the batch pro- 
cessing of the payment data after the normal users are 
finished with the system at the end of the day. The central 
facility is unable to perform the batch processing during the 
day since the batch processing would tie up the master files 
and present imacceptable delays to the normal users of the 
system in their attempts to gain access to the master files. 

Because the batch processing of the payment occurs at the 
end of the day, a delay of twenty four hours or more can 
occur between the time that a lock-box receives a customer*s 
payment through the mail and the time that the central 
facility posts the payment to the customer's account. This 
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delay can be especially problematic when the lock-box 
receives the payment on or just prior to the payment deadline 
since the system might erroneously assess a late payment 
charge lo the customer. The delay is also problematic in that 

5 normal users providing customer service and other mortgage 
services might not have the most up-to-date account infor- 
mation. As a result, the normal users would be unable to 
reconcile the account information that they access from the 
master files with the customer's own personal records. The 
conventional payment processing system therefore suffers 
from a disadvantage that payments may not be posted until 
a relatively long delay after a customer deposits a payment 
with a lock-box or other similar type of receiving facility. 

Another common problem facing batch processing of 
payment data is that the batch processing can adversely 
impact the normal day-time on-line functions. When the 
central processing facility receives a large amount of batch 
data, which occurs near the mortgage payment due date, the 
amount of time required to process the batch data signifi- 
cantly increases. During these heavy load times, the central 

20 facihty might have to delay the normal users from obtaining 
on-line access to the account data until the central facility 
has finished the batch processing. This added processing 
time is highly detrimental to the system since the on-line 
operations, such as customer service and other mortgage 

25 services, are temporarily suspended. 

These problems in batch processing are not limited to just 
the batch processing of mortgage payments but apply 
equally as well to other types of batch processing. For 
example, in addition to mortgage payments, payment pro- 

30 cessing systems suffer similar problems in delayed postings 
with car payments, credit card payments, and foreclosure 
related transactions. Furthermore, the problems with 
delayed postings are not special to payment processing 
systems but may be encountered in any type of batch data 

35 processing system. 

A previous processing system developed by the assignee 
of the present invention attempted to address some of these 
problems. 'ITie previous system was a BSS processing sys- 
tem used to process mobile home transactions. The system 

40 had a mover for transferring files, a router for assigning 
transactions to a driver, and a driver for processing the 
transaction. The BSS system had a monitor that tracked the 
completion of large bulk units of work. For instance, the 
handler might initially send two hundred transactions to be 

45 processed in conjunction with other on-line processing. At 
each minute, the handler would ensure that the system 
maintained this bulk amount of work by supplying addi- 
tional transactions equal in number to the number of trans- 
actions processed. Thus, if the handler detected that forty 

50 transactions of the original two hundred still need to be 
processed, the handler would supply an additional one 
hundred sixty transactions to maintain the two hundred 
back-log of work. The monitor used to control the speed of 
the system suffered from a disadvantage that the speed 

55 control was very slow to respond to environmental changes. 
For instance, the system would respond very slowly to any 
drop in processing from normal on-line users of the system 
and would likewise react very slowly to any increase in 
demand from these normal users. As a result, the processing 

60 of the transactions in the on-line environment presented a 
significant mount of interference with the normal users of 
the system. 

Thus, a need exists for a system or method for processing 
batch data which reduces the delays in posting updated 
65 information. Furthermore, a need exists for a system or 
method for processing batch data which reduces the amount 
of adverse effects on any on-line processing. 
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SUMMARY OF THE INVENTION files is updated by the payment drivers based on the pay- 

fji_j-.- * ments reflected in the payment transaction data. With the 

•nje invenlioD. m a preferred embodiment, is a paymen. ^ ^ completion time for each payment driver is 

processing system that mcludes a receivmg facihty for a number of drivers which are permitted to be 

receivmg payments and a cen ral faculty for processmg the ^ ^^.^^ ^ ^^^^^ completion 

payments, fhe receiving facility generates batch payment times 
data based on the payments to individual accounts and a 

batch convener in the central facihty converts the batch With the method accordmg to the mvention, the process- 
payment daU into payment transaction data for the indi- of payment transaction data can occur m conjuncUon 
vidual accounts. In the central facihty, a transaction mover with the provision of customer service and other types of 
places the transaction data on a transaction queue and a ^° ^ccoum services. Hie monitormg of the completion Umes 
transaction handler assigns individual transaction routers to allows the speed of the system to be comroUed m a such a 
the transaction data. The routers, in turn, assign the trans- ^ay that the processing of the payment transaction data does 
action data to payment drivers which actually process the no* Prevent the account services from accessing the master 
data by updating master files to reflect the payments. A files. The monitoring, furthermore, occurs a regular 
transaction monitor tracks completion times for each trans- intervals, such as every twenty milliseconds, which enables 
action driver and determines a number of drivers that may be speed of the process to be continuously monitored. Smce 
active based on the completion times. The monitor provides ^^e payment process can occur simultaneously with account 
speed control by writing the permissible number of drivers services such as customer service, the payments may be 
to a temporary storage queue which the handler subsc- processed during normal day-Ume hours and need not wail 
quenUy reads to Umit the number of active routers. "o^^ l^te at night. The method also mcludes steps of 
With the invention, data which is received in batch form classifying the payments into priority groups ^nd begmmng 
can be converted into transaction data and processed in an ^ ^^^"^ those transactions having the highest 
on-line environment. The facilities for receiving the pnori y. 

payments, such as lock-boxes, need not wail until the end of BRIEF DESCRIPTION OF THE DRAWINGS 
the day to transmit the data but may instead promptly 

transfer this data to be processed soon after the data is FIG. 1 is a block diagram of the processing system 

collected. In view of the speed control enacted through the according to a preferred embodiment of the invention, 

monitor, the processing of the converted data can occur FIG. 2 is a flowchart of a processing method according to 

during the day-time hours and need not be delayed unti! late a preferred embodiment of the invention, 

into the night. Consequently, customers are able to obtain ^^^^^^ diagram of the processing system shown 

updated information on their accounts in a much more pjQ j 

expedient manner. Further, since updates to the accounts are „_ „ u ^ c *• u#ujf** 

*j . . , ' / . J FIG. 4 is a flowchart for converting batch data to trans- 
made much more quickly, customer service and other action data 
accoimt services are not disadvantaged but may instead 

provide their services in a much more efficient and timely 5 is a flowchart of operations for the handler shown 

manner. ^■ 

The monitor advantageously provides continuous speed ^ is a flowchart of operations for a start-up routine 

control of the system, llie monitor derives an average of the handier. 

completion rate for the drivers and, based on this value, 4q FIG. 7 is a flowchart of operations for the mover shown 

adjusts the number of permissible drivers accordingly. The in FIG. 3. 

number of drivers, however, is limited by a maximum FIG. 8 is a flowchart of operations for the router shown in 

number so as to limit the maximum speed of the system. piG. 3. 

With this speed control, the system is able to quickly sense ^ ^ ^ flowchart of operations for the driver shown in 

environmental conditions impacting on the amount of pro- 45 ^ 

cessing power avaflable for the payment transaction data and T^^\n - .j- u 

, J . .u • * 1 J *- * FIG. 10 is a block diagram of the payment driver shown 

can quickly respond to the environmental conditions so as to . ^ ^ ^ 

minimize the effects of the payment processing on the other ^ 

on-line processes 11 is a flowchart of operations for a CAT transaction. 

-nie processing system preferably receives payments from 50 ^ ^^'^^^^ ^^^^'^"^ ^^"^ 

a plurality of different sources, such as a lock-box facility, a ^• 

CAT or other automated teller machine, an enhanced FIG. 13 is a flowchart ofopcrations for the monitor shown 

telephone, or a personal computer. Each of these payments ^ FIG- 3- 

can be processed at the processing sj^em vWthout disrupting DETAILED DESCRIPTION OF THE 

normal on-hne users of the system^TTiese differen types of 55 PREFERRED EMBODIMENT 

payments are preferably classified into different pnority 

groups with the CAI' payments being processed first fol- Reference will now be made in detail to the preferred 

lowed by the lock-box payments and then other batch embodiment of the invention, an example of which is 

payments. illustrated in the accompanying drawings. The invention is 
A processing method according to a preferred embodi- 60 described with reference to a system 10 for use in a financial 

ment of the invention includes the steps of receiving pay- institution to track mortgage payments apphed to individual 

ments and generating batch payment data at a receiving accounts. It should be understood, however, that the inven- 

facflity. The batch payment data is transferred to a central lion can be applied to other types of accounts, such as to 

facility and is converted to transaction data. The transaction accounts for financing mobile homes, automobiles, or stu- 
data is then moved to a temporary queue and is assigned to 65 dent loans. 

transaction routers and to individual payment drivers. Next, With reference to FIG. 1, a processing system 10 accord- 

the information in individual accounts located in the master ing to a preferred embodiment comprises a process facility 
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management (PFM) system 12 for receiving mortgage pay- 
ment data received from a plurality of different sources. 
These sources include a customer activated terminal (CAT) 

13, which is a particular type of automated teller machine 
(ATM), an enhanced telephone 15, a personal computer 16, 
and at least one lock-box facility 17. Each of these sources 
13 and 15 to 17 may be used for some more traditional 
functions, such as transferring funds between checking and 
savings accounts, and can also perform some more non- 
traditional fiinctions, such as bill payment, information 
retrieval, and transferring funds between money market 
accounts, checking accounts, and savings accounts. The 
transactions originating at the CAT 13 are processed directly 
by the PFM system 12 while the transactions originating at 
the enhanced telephone 15 and personal computer 16 are 
processed by the PFM system 12 indirectly through a home 
services delivery system (USDS) 14. 

The CAT 13 is a particular type of ATM built for the 
assignee and its affiliates by Citicorp Transaction Technol- 
ogy and the HSDS 14 is a proprietary service platform for 
providing an interface between the enhanced telephone 15 
and the personal computer 16. The CAT 12 and the HSDS 

14, however, may be replaced with any suitable type of ATM 
or service platform, respectively. The enhanced telephones 
have been developed by an affiliate of the assignee, 
examples of which are described in U.S. Pat. Nos. 4,991, 
199; 5,088,927; 5,195,130; and 5,321,840, which are hereby 
incorporated by reference. 

Tti G lock-box fa cility 17, in general, is a well known 
facility for receiving p ayments and for transmitting the 30 
paymcntruata to a processing f acilit y. While the lo ck-box 1 7 
maycomprise^ly a single lock-boxTthe processing system 
10 pTeferatily comp rises a plu rality ot locK^xes 17 which 
are located at'various locations throughout a geographic 
region. The lock-boxes 17 receive payments in the mail and'^5 
have scanning equipment for acquiring account information 
from the contents of the mail, namely payment coupons and 
enclosed checks. The l ock-boxe s 17 collect the accou nt 
information in batch-form and transmit this data to the P FM 
system 127 Whereas previous lock-boxes typically transmit- 40 
ted their batch data to a processing farili'ty c\^]y fimawo-ihe 
end^ofajia>i,_the lock-boxes 17 according to the invention 
preferably transmit the batch payment information at much 
more frequent intervals throughout the day. For instance, the 
lock-boxes 17 may transmit at regular intervals, such as 45 
every two hours, or may alternatively transmit once a certain 
amount of payments have been received, such as ten thou- 
sand payments. By transmitting more frequently, the pro- 
cessing system 10 can more quickly update account infor- 
mation based on the received payments. 

The normal users 18 of the processing system 10 include 
those people who must access account information so as to 
provide customer service or to provide other types of 
mongage processing. The normal users 18 arc on-line users 
of the PFM system 12 which require approximately real- 
time access to the account information so as to provide 
substantially real-time service to the customers. ITie normal 
users 18 of the system 10 generally work between the hours 
of 7:00 a.m. and 6:00 p.m. and thus present their heaviest 
load to the system 10 during these hours. 

A method 20 generally illustrating operations of the PFM 
system is shown in HG. 2. At a step 21, data is received in 
batch form, such as from the lock-box facility 17. Next, at 
step 22, the batch data is converted into transaction data and, 
at step 23, the transaction data is moved to a transaction 65 
queue. The transaction data is routed at step 24 to an 
appropriate driver which, at step 25, updates account infor- 
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mation according to the received transaction data The 
method 20 for processing the mortgage payment data occurs 
in conjunction with on-line processing, such as the customer 
service and other mortgage services. These services, 
however, are not halted due to the processing of the payment 
data and updating of the account information but, as will be 
become apparent from the description below, occur without 
any serious interruptions in service. 

A detailed diagram of the PFM system 12 is shown in 
FIG. 3. To simplify the diagram, some of the data files have 
been illustrated in more than one place so that the data files 
may be placed in close proximity to the devices that access 
those files. The PFM system 12 is an asynchronous process- 
ing system comprised of a transaction handler 31, a trans- 
action mover 32, a transaction router 33, drivers 34, and a 
transaction handler monitor 35. In general, the handler 31 
determines when data is available for processing within the 
PFM system 12. The handler 31 selectively starts the trans- 
action mover 32 and assigns transactions to specific trans- 
action routers 33 and the transaction mover 32 transfers data 
from temporary queue files to a transaction queue file. The 
router 33 accepts transactions assigned by the handler 31 
and presents them from the transaction queue to an appro- 
priate driver 34. The drivers 34 comprise different types of 
drivers 34 for different types of transactions with each driver 
34 processing a transaction and updating the account infor- 
mation. The drivers 34 process one transaction at a time and 
inform the router 33 whether the update was successful. 
When the update is successful the router 33 deletes the 
transaction from the transaction queue. The transaction 
handler monitor 35 tracks the consumption of resources by 
the PFM system 12 and provides speed control so that the 
normal users 18 can continue to obtain on-line services with 
only minimal delays. 

t\ The batch data from the lock-box facilities 17 and from 
other batch data sources is received at a batch converter 38 
which converts the data from a batch format to a transaction 
format. FIG. 4 provides a flowchart of the general operations 
of the batch converter 38. After the batch data is received at 
step 81, the batch converter 38 verifies at step 82 that the 
data is not duplicative of data which has already been 
received. Next, at step 83, the batch converter 38 converts 
the data from the batch format to the transaction on-line 
format. The batch data typically arrives in a format with 
account and payment information for all of the accounts 
followed by a single entry of the date covering all of the 
payments. The batch converter 38 reformats the data so that 
the information for each account includes not only the 
account number and payment amount but also includes the 
effective date of the payment, yVfler converting the data 
format, the batch converter 38 validates a nd edits the tran s- 
action__dat a at step__84. Duri ng this step_84, _the_batch_ 
converter 38 performs sucb^ functions as determin ing 
whBlKe rlhc account is an existing accoun t, determining" 
whetlier me payment amount is the amount due, and deter- 
mining whether the payor is not in bankruptcy. As a last step 
85, the batch converter 38 U-ansfers the transaction data to 
temporary pay queues, such as lock-box temporary pay 
queue 39, CAI' temporary pay queue 40, and other batch 
temporary pay queue 42. 

The transaction handler 31 in the PFM system 12, more 
specifically, is an asynchronous unit for conU-olling the 
mover 32 and the routers 33 and maintains a temporary 
storage queue within a handler mover control interface file 
52. The handler 31, with reference to FIG. 5, reads this 
temporary storage queue at step 91 and, based on the 
information in the temporary storage queue, determines at 
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Step 92 whether the mover 32 should be activated. The PFM system 12 and increasing the speed and efiSciency of 

mover 32, as discussed above, transfers files from temporary the PFM system 12 

pay queues to a transaction queue 41 and is preferably A method 100 by which the PFM system 12 and the 

placed in a wait slate once all files have been transferred. handler 31 start-up will now be described with reference to 

The handler 31 will wake the mover 32 at regular intervals 5 FIG. 6. At step 101, a batch job executor 44 performs a 

which are specified within the temporary storage queue number of batch jobs, such as batch jobs for initializing the 

located in the handler mover control interface file 52. The operations of the PFM system 12. After all batch jobs have 

handler 31 preferably activates the mover 32 every five completed, a transaction handler starter 45 is activated in 

minutes, but may alternatively activate the mover 32 at a order to start the handler 31. Once the handler 31 is started, 

greater or lesser interval of time. If the mover 32 should not jq the handler 31 will read the calendar records from a security 

be activated, as determined at step 92, then processing file 47 and determines whether the present date and lime are 

continues to step 98 at which time the handler 31 will within the start and stop times indicated by the calendar 

become idle. Each time that the handler 31 is reactivated, the records. If the present time and date are outside the permis- 

processing returns to step 91 so that the handler 31 can once sible range of operating times, then the handler 31 will 

again read the temporary storage queue and detect any ^5 become inactive. For instance, if the calendar records only 

change to the temporary storage queue. permit weekday operations of the handler 31 and the handler 

The router 33, as discussed above, is generally respon- 31 is started on a weekend, the handler 31 will conclude 

sible for assigning transactions to specific drivers. The router from the calendar records that it must hall operations and 

33 preferably comprises a plurality of routers 33, the number become inactive. On the other hand, if the present time and 

of which is controlled by the handler 31. The handler 31 20 d^*® permit the operation of the handler 31, then the handler 

determines the number of routers 33 which may be active at 31 will activate a verify file availability device 51 to verify 

one lime based on the information read from the temporary that all files needed for processing the payment data are 

storage queue within the handler mover control interface file available. The verify device 51 performs this verification by 

52. The routers 33 trap all abend conditions either of itself attempting to read all of the necessary data files. When the 

or its corresponding drivers 34. When an abend condition 25 verify device 51 is unable to read any one of the necessary 

occurs, the router 33 will pass information to the handler 31 files, the verify device 51 will report this inability to the 

to ensure that no additional routers 33 are started so that all handler 31. Since any processing by the handler 31 will 

transactions will remain on the transaction queue file 41 likely encounter a critical error when one of the necessary 

until the abend can be repaired. As will become apparent files is unavailable, the handler 31 will not initiate process- 

from the description below, the number of routers 33 is 30 ing of the transaction data but will instead become inactive, 

altered in order to selectively control and limit the speed of If all files are available and if the present time and dale are 

consumption by the processing system 10. By limiting and within the permitted start and stop times reflected in the 

controlling the number of active routers 33, the normal users calendar records, then the handler 31 begins the processing 

18 of the system 10 can continue to perform their services of transaction payment data and other processing functions 

while the PFM system 12 processes the mortgage payment 35 at step 106. The handler 31 will then process the transaction 

information and updates the account information. data until all of the data has been processed, at which time 

In order to track the active routers 33, the handler 31 the handler 31 wiU become inactive by executing a CICS 

maintains a set of slots within a slot intervals storage file 57 DELAY command. In accordance with the method 90 shown 

with each slot representing an active router 33. Depending in FIG. 5, the handler 31 will read the temporary storage 

upon the load to the PFM system 12, as many as one hundred 40 queue in the handler mover control interface file 52 upon 

twenty slots or more may be filled, thereby corresponding to being reactivated and will activate the mover 32 at the 

an equally large number of active routers 33. The handler 31, intervals specified in the file 52. 

at step 94 determines whether any slots are available. If no The security file 47 is a KSDS VSAM file and contains 

slots are available, then the handler 31 will wait at step 94 defauh information which is transferred to the handler 

until a slot becomes available. With at least one slot 45 mover control interface file 52. The handler 31 uses this 

available, the handler 31 next reads the transaction data from default information, inter alia, to control when the handler 

the transaction queue 41 and assigns the transaction data to 31, mover 31, and routers 33 are activated and deactivated 

the open slots. At step 96, the handler 31 assigns a router 33 and, for the routers 33, the number of routers 33 which may 

to the slot and activates the router 33. The handler 31 next be active at a time. In response to manual inputs 49 to a 

determines, at step 97, whether additional transaction data 50 CICS on-line screen, a transaction handler default device 48 

needs to be assigned to a router 33. If so, then the handler can modify the default values. Since the default values are 

31 returns to step 94 and waits for a slot to become available transferred to the handler mover control interface file 52 

for the additional data. If, on the other hand, all transactions during start-up, any change in the default values through the 

have been processed, then the handler 31 waits in an idle transaction handler default device 48 will not become effec- 

state at step 98. Thus, the handler 31 continuously updates 55 live imtil the handler 31 is restarted. The information in the 

the slots as the routers 33 complete their tasks and become handler mover control interface file 52 may also be altered 

available and as the routers 33 become assigned to specific dynamically by routing manual inputs from an input/output 

transaction data. device 71 to the transaction handler monitor 35. 

Rather than routing only a single record to each router 33, The transaction mover 32 transfers data from temporary 

the handler 31 preferably transfers a vertical group of 60 transaction queues, namely the lock-box temporary pay 

records from the transaction queue file 41 to each router 33 queue 39, the CAT temporary pay queue 40, and the other 

Each vertical transaction group comprises a plurality of temporary pay queue 42, to the transaction queue file 41. 

records, such as three records, and are transferred to the The lock-box temporary pay queue 39 is an entry sequence 

router 33 as a group package. By placing the transactions data set (ESDS) virtual storage access method (VSAM) file 

into vertical groups, the amount of processing incurred by 65 that contains all batch lock-box payments transferred by the 

the handler 31 in handling the transactions is reduced, batcbconverter38. A temporary other transaction pay queue 

thereby reducing the overall processing overhead within the 42 is also an ESDS VSAM file but contains other types of 
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transactions transferred by the batch converter 38. These having the next highest priority at step 117 and returns to 

other types of transactions include, but are not limited to, step 114 to transfer these &les. If on the other hand, all 

appraisal tracking transactions and TORIE transactions. The queues have been processed by the mover 32, then at step 

transaction queue 41 is a KSDS VSAM file which contains 118 the mover 32 informs the handler 31 that the transfer of 

all lock-box and CAT payments copied from the temporary 5 files from the temporary pay queues to the transaction queue 

payment queues 39, 40, and 42. The transaction mover 32, 41 has been completed. The mover 32 informs the handler 

as well as the PFM system 12, is not limited to just three 31 at step 118 by writing a status of "DO^fE" for die mover 

temporary transaction queues 39, 40, and 42, but may 32 within the handler mover control interface 52 file. At this 

interact with additional temporary queues, point in the method 110, the mover 32 remains inactive at 

A method 110 of operation for the mover 32 is generally 30 ^^®P ^ handler 31 once again activates the mover 

shown in FIG. 7. The mover 32 remains in a wait state at step ^2. 

Ill until the handler 31 activates the mover 32. As discussed Before transferring the files to the transaction queue 41 at 

above, the handler 31 activates the mover 32 at intervals step 114, the mover 32 also provides any special handling 

specified by the temporary storage queue stored in the which might be specified within the mover queue records, 

handler mover control interface file 52. After the mover 32 ^5 For instance, with payments, the mover 32 passes each 

is activated, the mover 32 will read mover queue records at record in each queue to a cash loader 62. 'llie cash loader 62 

step 112. The mover queue records are stored in a router/ performs special processing by summing the total amount of 

mover error file 53 and contain information for determining, payments within each batch. The cash loader 62 generates a 

inter alia, the order in which the temporary queue files will batch header and payment total and supplies this information 

be processed. The mover 32 internally sorts these files in a 20 *° ^ drawer update device 63. The cash drawer update 

table based on priority codes, with the files having lower device 63 maintains a cash drawer file 74 so as to perform 

priority code numbers being processed before the files with a cash balancing process between the total amount of the 

the higher priority code numbers. Apriority code of "S" can payments received in batch and transferred by the mover 31 

be used to skip a queue completely. The priority codes for and the total amount of the payments processed by the 

the queues can be changed by altering the mover queue 25 various drivers 34. After all processing has been completed 

records using a transaction mover queue update device 55 for a batch, these two amounts are compared to each other 

and an input/output device 72. Any change in the priority to detect any discrepancies. The cash drawer update device 

codes will not become effective until after the next time the 63 is the only device that can directly access the cash drawer 

mover 32 is started. file 74. 

In the preferred embodiment, the transactions can be 30 A method 120 of operation for the routers 33 is generally 

classified into three different priority groups. The first group, shown in FIG. 8. The method 120 includes a step 121 of 

having the highest priority, is dedicated to CAT payments receiving a transaction from the handler 31. As discussed 

Since the customer is waiting at a CAT or other ATM for a above, the handler 31 controls the number of router 33 

transaction receipt, these CAT payments should be pro- which may be active at any one time and also supplies the 

cessed as quickly as possible in order to reduce the time that 35 routers 33 with the transactions in vertical groups. After a 

the customer must wait for the receipt. The middle priority router 33 receives a transaction or group of transactions 

group is reserved for the high volume batch transactions from the handler 31, the router 33 next determines the type 

received fi-om the lock-box facility 17 and the low priority of driver 34 needed to process the transaction. The preferred 

group of transactions is reserved for other transactions embodiment has four types of payment drivers: a payment 

received in batch form. Although the transactions have been 40 driver 34a, an appraisal tracking driver 346, a TORIE driver 

classified into only three priority groups, the transactions 34c, and a CAT payment driver 34rf. It should be understood, 

could alternatively be grouped into a greater or lesser however, that the PFM system 12 may include additional 

number of groups. drivers 34 of the same type or of different types. 

At step 114, the mover 32 transfers files from the tem- At step 123, the router 33 passes each transaction to the 

porary pay queues 39, 40, and 42 to the transaction queue 41 45 appropriate one of the drivers 34. When the handler 31 sends 

according to the relative priority between the queues. The a vertical group of transactions to a router 33, the router 33 

mover 32 first turns to the temporary pay queue having the will pass the transactions one -by-one to the appropriate 

highest priority and reads all transactions which are located driver 34. If the driver 34 successfully processes the 

after the last file read during a previous transfer by the mover transaction, as determined at step 124, the router 33 will 

32. A relative byte address (RBA) of the last file read by the 50 delete the transaction from the transaction queue file 41 at 

mover 32 is stored in the mover queue record and is read by step 125. The router 33 will also update the slot for the 

the mover 32 at step 112. Thus, at step 114, the mover 32 just-completed transaction by writing the time elapsed in 

reads all files after the RBA stored in the mover records processing the transaction by the driver 34 into the slots 

queue and then writes these files to the transaction queue file interval file 57. When the router 33 receives a vertical group 

41. Next, at step U5, the mover 32 updates the mover 55 of transactions, the router 33 will wait until all transaction 

records queue in the router/mover error file 53 by writing the are processed before updating the appropriate slot within the 

new RIB A for the last record transferred by the mover 32. slots interval file 57. As will become apparent from the 

If any one of the files cannot be opened, the mover 32 will description below, the elapsed times for the transactions are 

update the handler mover control interface file 52 with a used by the handler 31 to determine throughput. If a trans- 

stams of "WAFTING" and the mover 32 will remain inactive 60 action is not successfully processed by a driver 34, the router 

until it's next start-up time. If an I/O error occurs during the 33 will write an error record to the router/mover error file 53 

transfer operation, the mover 32 will update the handler and the router 33 will leave the transaction on the transaction 

mover control interface file 52 with a status of "STOPPED." queue file 41. 

At step 116, the mover 32 determines whether additional A method 130 generally illustrating operations of the 

queues have files that need to be transferred. If one or more 65 drivers 34 will now be described with reference to FIG. 9. 

queues do have files that need to be transferred to the After the driver 34 receives a transaction from a router 33 at 

transaction queue 41, then the mover 32 turns to the queue step 131, the driver 34 validates and edits the transaction at 
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Step 132. At step 132, the driver 34 performs some of the processing, the history file 147 is emptied while the trans- 
same editing and validating that was already performed actions in the log file 148 are added to the history file 147. 
when the files were placed in temporary pay queues, such as In addition to the master files 58, as staled above, the 
by the batch converter 38. For the payment driver 34fl and payment driver 34a also accesses a PFM memo file 68 and 
CAT payment driver 34^, this editing is performed by a 5 the error resolution file 59. The PFM memo file 68 will be 
payment editor 64 which both edits and distributes payment described in more detail below with reference to the pro- 
transactions. The validate and edit step 132 is a necessary cessing of transactions received from a CAT 13. The error 
step since the status of the account might have changed from resolution file 59 is a KSDS VSAM file containing two 
when the files were placed in the temporary pay queues. The record types used in the processing and the on-line correc- 
validation and editing at the batch converter 38, on the other jo of processing. The first type is error records which track 
hand, may be eliminated in view of this process being the transactions that have failed the edits performed by the 
performed by the drivers 34. Next, at step 133, the drivers payment driver 34fl, the appraisal tracing driver 34b, the 
34 post the transaction to the set of master files 58 which TORIE driver 34c, or the CAT payment driver 34d, These 
contain all of the information for the various accounts. If a error records are exact duplicates of the transactions fi-om 
critical error occurs during the posting, as determined at step 55 the transaction queue file 41. 'llie payment error records can 
134, the router 33 will write an error record to the router/ be resubmitted or deleted during an on-line PFM error 
mover error file 53 and the router 33 will stop operations. If resolution process while the two other transactions are used 
a data error occurs during the posting, the driver 34 will only for on-line display and batch reporting. The second 
write an error record to an error resolution file 59 and the type of records is log records which track the payment error 
router 33, in this situation, will continue to operate. When no 20 records that were resubmitted or deleted in the on-line PFM 
errors arc encountered, the driver 34 will inform the router error resolution processing. Both of these records are 
33 that the posting of the transaction was successful at step reported and deleted from the file in nightly batch process- 
138. ing. 

The payment driver 34fl, more specifically, handles what The appraisal tracking driver 34b and the TORIE driver 

are considered regular payments to the mortgage accounts 25 process one transaction at a time from the vertical 

received through the lock-box facility 17. The payment transaction group associated with a calling router 33 and 

driver 34fl, in addition to the functions described with informs the router 33 whether the processing was successful, 

reference to FIG. 9, also activates the cash drawer update lo general, the appraisal tracking driver 34b and the 1X)R1E 

device 63 to either post or back -out detail cash amounts from driver 34c handle updates to a benchmark file 76 sent from 

the cash drawer file 74 based on whether the payment 30 some of the other users, namely a LAN subsystem via 

transaction processed by the driver 34fl was successfully TCP/IP. The benchmark file 76 is a KSDS VSAM file that 

posted to the master files 58. Thus, if the posting was contains benchmark data entered on-line or updated from the 

successful, the cash drawer update device 63 will sum the appraisal tracking driver 34b or the TORIE driver 34c. The 

posting with a running totals of all postings for the particular transactions handled by the appraisal tracking driver 34^? and 

batch. By recording both the total amount posted by the 35 the TORIE driver 34c are appraisals and other real estate 

payment driver 34fl and the total amount loaded into the cash owned property, respectively. 

drawer file 74 by the cash loader 62, the PFM system 12 can A method 150 generally illustrating the processing of 
ensure that all payments have been processed. In all, through mortgage payments received by a CAl' 13 is shown in FIG. 
the payment driver 34a and cash drawer update device 63, 11. The transactions received by a CAT 13 are handled 
the cash drawer file 74 maintains records of all transactions 40 differently than other payments, such as from a lock-box 
which are entered, all transactions which are rejected, all facility 17, since the payor or customer requires some type 
transactions which are posted, the total amount of cash of receipt quickly fi-om the PFM system 12 and, moreover, 
entered, the total amount of cash rejected, and the total quickly requires this receipt at any lime of the day. At step 
amount of cash posted. 151 of the method 150, the transaction from the CAT 13, or 
The functions of the payment driver 34fl will now be 45 from any other suitable ATM, is received by the CAT 
described in more detail with reference to FIG. 10, which payment driver 34d, As with the other drivers 34, at step 152 
shows a partial view of the PFM system 12. The payment the CAT payment driver 34d validates and edits the trans- 
driver 34a receives transaction data from the router 33 with action to ensure, inter alia, that the amount paid is the 
this transaction data including information directed to the amount due and that the payor is not in bankruptcy. Next, at 
principal, interest, escrow and other miscellaneous items 50 step 153, the CAT driver 34d writes a record to the memo 
making up a monthly mortgage obligation. Because these post file 68, which is a KSDS VSAM file, and then, at step 
various portions of the mortgage payment must be tracked, 154, posts the transaction to the CAT temporary pay queue 
the DLS master files 58, shown in FIG. 3, are comprised of 154. The master files 58 are placed in a read-only mode 
the various files shown in FIG. 10. These files include a during CICS batch processing, whereby any update to 
KSDS VSAM mortgage file 141 for containing account- 55 accounts must be posted to the memo post file 68 to allow 
level mortgage information, a KSDS VSAM alter file 142 the customer to see the results of their payments immedi- 
for containing account-level adjustable rate mortgage ately. When the handler 31 and subsequently the payment 
information, a KSDS VSAM escrow file 143 for containing driver 34fl are later activated, the payments will be trans- 
accoimt-level escrow information, a KSDS VSAM miscel- ferred from the CAT temporary pay queue 40 to the trans- 
laneous file 144 for containing account-level miscellaneous 60 action queue 41 by the mover 32, will be assigned to one or 
mortgage information, a KSDS VSAM PFM history file 147 more routers 33, and will then be processed by the payment 
for containing daily financial transactions, and an ESDS driver 34a and permanently posted to the master files 58. 
VSAM log file 148 for containing daily transactions entered After the payment driver 34^ successfully posts the CAT 
through PFM matrix processing or through on-line DLS transaction to the master files 58, the payment driver 34fl 
transactions. The PFM, history file 147 is a read-only file in 65 deletes the CAT transaction from the memo post file 68. 
the on-line environment and contains the updates only imtil With reference to FIG. 12, the CAT payment driver 34d 
on-line operations are terminated. During nightly batch can gain read-only access to the master files 58, which are 



08/07/2003, EAST Version: 1.04.0000 



5,940,813 

13 14 

Specifically shown as the mortgage file 141, the alter file tolerance band is from 3 to 6.3 seconds with a daily average 

142, the escrow file 143, and the miscellaneous file 144. As of 4.65 seconds and an available daily processing time of 14 

discussed above, the CAT driver 34(faeeds to access the hours. At a maximum speed limit of 30 concurrent transac- 

information in these files in order to provide the customer tions with a daily average of 24, an IS per second value, 

with a receipt and with updated information on the account 5 defined by IS/Average Cbmpletion Rate, is equal to 214K/ 

but does not perform the actual updating of the master files 4.65, or 46K per second. At an average of 24 concurrent 

58. Rather, the payment driver Ma will perform this func- drivers 34, the PFM system 12 has a value of 1.1 MIPS, 

tion of updating the master files 58. The CAT driver 34d, The throughput rate for the PFM system 12 can be 

however, can both read and write files to the PFM memo calculated as 24/4.65 or 5.16 transactions per seconds with 

post file 68 and can write files to the transaction queue 41. jq the 85% value of this rate being 4.39 transactions per 

The monitor 35, in general, evaluates the CICS environ- second. The rate per hour is thus 15.8K transactions and the 

ment and passes information to the handler 31 through the rate per a 14 hour day is 221.3IC The 20% overhead includes 

handler mover control interface file 52. The information Jlf exeoition code for the handler 31, mover 32, and router 

passed to the handler 31 relates to the actual completion of f ^x^^.c^^cf ''^''k ''"i'^^ ''T'^ ^ 

existingdrivers34,timedelaysindrivercompletion,manual 35 overhead plus MVS/ESA overhead. Tlie above calculations 

^ ° , . . , u ji n J -1 r are based on a vertical group contaimcg only one transac- 

control orders issued to the handler 31, and amval of ^.^^ transactions are processed S part of a vertical 

additional transactions. The momtor 35 also provides speed ^^^^ ^^^^ transaction, the PFM system 12 

control to the PFM system 12 v/ith this speed control being ^^^^^ ^^^^ ^^^^^^^ throughput per transaction, 

focused on the routers 33 and the driver^ 34. Hus informa- ^ ^^^^^^ ^^^^j summarizing the operations of 

tion also has default values which may be transferred from 20 the monitor 35 is shown in FIG. 13. At step 161, the monitor 

the security file 47 to the handler mover control mterface file 35 ^^^^ ^^^^ ^ ^^^^ intervals file 57 relating to the 

52. The monitor 35 further prohibits the handler 31 from completion times for the drivers 34. From this data, the 

exceeding a maximum number of router 31 and driver 34 monitor 35 determines the average point-to-point comple- 

combinations and thus limits the maximum speed of the tion rate at step 162. Based on the point-to-point completion 

PFM system 12, The monitor 35 provides this speed limit by 25 rate and on the data stored in the handler mover control 

issuing an immediate "STOP" command to the handler 31 if interface file 52, the monitor 35 next specifies the number of 

the maximum number of combinations has been exceeded. permissible routers 33 at step 164 and the number of 

Advantageously, the monitor 35 continuously evaluates the permissible drivers 34 at step 165. For example, if the 

CICS environment and continuously checks the speed of the point-to-point completion rate is between 1.0 second and 1.6 

PFM system 12, whereby the PFM system 12 can react 30 seconds, the number of drivers 34 is not changed. The 

almost instantaneously to any variances in load to the PFM number of drivers 34, however, is increased when the 

system 12. point-to-point completion rate is less than 1.0 second and is 

The monitor 35, more specifically, determines a through- decreased if the point-to-point completion rate is above 1.6 

put rate of the PFM system 12. This throughput rate can be seconds. The monitor 35 will then perform appropriate 

expressed mathematically as: (F(Z)/F(X))xF(Y), where 35 updates to the handler mover control interface file 52 at step 

F(X) is the average point-to-point completion rate for the 166- The monitor 35 adjusts the number of routers 33 and 

drivers 34, F(Y) is the hours of available processing opera- drivers 34 so that the consumption varies according to a step 

tion time, and F(Z) is the average number of running drivers progress curve with a maximum plateau defined by the 

34. As an example, the processing system 12 has been shown speed limit of the PFM system 12. After the handler mover 

to have an average point-to-point completion rate F(X) of 40 control interface file 52 has been updated, the processing 

3.5 seconds, has 16 hours of available processing time F(Y), returns to step 161 so as to provide a continuous method 160 

and has an average F(Z) of 40 drivers 34. Consequently, the for monitoring the speed and consumption of the PFM 

PFM system 12 has been established to have a throughput system 12. 

rate of (40/(3.5 sec))x(16 hours)-658K. Actual throughput By continuously tracking the speed of the PFM system 12, 

data has shown that 85% of overall throughput can be 45 the monitor 35 ensures constant and even resource consump- 

achieved with a tme value of about 559K. The overall tion throughout the CICS processing day without the 

throughput rate, however, can be reduced by factors such as 'spikes' that usually occur with other conventional process- 

the available number of running hours F(Y), file placement ing systems. The monitor 35 self controls the resource 

on DASD which would increase the point-to-point comple- consumption, whereby terminal slow-down and response are 

tion rate F(X), and the average number of running drivers 34 50 controlled. The PFM system 12 will consume resources 

F(Z). If service was reduced from 16 hours to 14 hours, the when they arc available up to a maximum speed limit with 

number of concurrent transactions was reduced from 40 to continuous monitoring of demand load by the monitor 35. In 

30, and the completion rates were increased from 3.5 this way, the PFM system 12 balances itself with other 

seconds to 7 seconds, the throughput rate would be 216K activity occurring in CICS. 

and the 85% value of this rate would be 183K. Thus, as an 55 The PFM system 12 has a number of input/output units for 

extremely low estimate, portfolios of about 900K accounts permitting manual control of the system 12. These input/ 

could be supported by the PFM system 12 assuming that one output units are designated as elements 49, 71, and 72. The 

fifth of the payments all arrive on one day, input/output unit 49 can supply inputs to the calendar record 

The monitor 35 also determines and tracks the consump- maintenance device 46 which maintains the calendar records 

tion rate in million instructions per second (MIP). The 60 stored on the security file 47. The calendar records, as 

payment drivers 34 each has an associated instruction set IS, discussed above, are used to determine what days and during 

which is equal to F(BI)+(0.2xF(BI)), where F(BI) is the base what hours the handler 31 and mover 32 are to be active. The 

instruction set having approximately 178K, the factor of calendar records maintenance device 46 maintains the fol- 

(0.2xF(BI)) relates to overhead execution at a level of 20%, lowing fields: the date, a reason code which is blank for a 

and IS specifies the total instruction set. The total instruction 65 work day, W for a weekend, and H for a holiday, handler 

set IS for the preferred embodiment is thus 178K+ start and stop limes, and mover start and stop times. These 

(0,2*178K), which is 214K. An average completion range or fields may be modified through the input/output device 49. 
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The input/ouiput device 49 is also connected to the 
transaction handler defaults device 48. The transaction han- 
dler defaults device 48 maintains the handler 31, naover 32, 
and router 33 defaults stored in the handler records on the 
security file 47. The defaults are loaded to the temporary 5 
storage queue in the handler mover control interface file 52 
when the handler 31 is started. The following fields may be 
altered through the input/output device 49: maximum num- 
ber of routers 33, default number of routers 33, decrement 
factor in routers 33, increment factor in routers 33, elapsed jq 
averages in milliseconds both high and low for the routers 
33, bypass transaction codes for the routers 33, start inter- 
vals in milliseconds for the mover 32, retry interval in 
milliseconds for the mover 32, retry count for the mover 32, 
and maximum records for the mover 32. ^5 

The input/output device 49 is further connected to the 
transaction queue inquiry device 66. The transaction queue 
inquiry device 66 provides data to the input/output device 49 
for displaying the payments appearing on the payment 
transaction queues 39, 40, and 42 and serving as inputs to the 20 
mover 32. Although each queued transaction has the ability 
to carry other transaction codes, the transaction queue 
inquiry device 66 preferably only shows key payment 
information, but could alternatively provide additional infor- 
mation, llie data displayed by the input/output device 49 25 
will be dynamic in nature especially iif the payment driver 
34fl or the CAT payment driver 34^^ are active. In general, 
the transaction queue inquiry device 66 and input/output 
device 49 allow users to determine the status of the queues 
at any specific point in time. 39 

The input/output device 71 provides on-line control of the 
monitor 35. As discussed above, the monitor 35 monitors 
and manipulates the operations of the handler 31, mover 32, 
and routers 33 by altering the contents of the temporary 
storage queue in the handler mover control interface file 52. 35 
The device 71 permits dynamic updates to some of the 
functions taking affect immediately but remaining in effect 
only until the handler 31 is deactivated. When the handler 31 
is then reactivated, the system defaults stored in the handler 
record on the security file 47 will take affect. 40 

A group of the updates that may be entered through the 
device 71 relate to the handler 31, which is associated with 
a type code "H." These updates include a start update, 
having an action code "S," used to manually start the handler 
31. When requested, the verify file availability device 51 45 
will execute to determine if all files used by die PFM system 
12 are active to CICS. The calendar record stored on the 
security file 47 corresponding to the current date is then 
accessed to verify that the current day is a work day and the 
time of day is within the start and stop times stored on this 50 
record. If all edits are passed, a CICS START command for 
the handler 31 is executed through the device 71. Another 
update is a stop, having an action code "P," which is used to 
manually stop the handler 31. In order for the stop to be 
effective, the mover 32 and routers 33 must also be stopped. 55 
The mover 32, however, can only be stopped when no 
transactions are actively being moved while the routers 33 
can be stopped at any time. A further update, having an 
action code "T," is used to dynamically change the start and 
stop times of the handler 31 overriding the times loaded 60 
from the calendar record stored on the security file 47. A slot 
update, having an action code "N," is used to dynamically 
change the default and maximum number of slots used to 
control the routers 33 and overrides the values loaded from 
the handler default record stored on the security file 47. An 65 
inquiry function, having an action code "I" is used to show 
the status of the handler 31 and a variances function, having 
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an action code "V," dynamically changes the high and low 
elapsed averages in milliseconds used to control the routers 
33 and overrides the values loaded from the handler default 
record stored on the security file 47. 

Another update that may be accomplished through the 
input/output device has a type code of "Q" and is directed to 
handler queue requests. An action code of "P" for stop is 
used to manually delete the temporary storage queue in the 
handler mover control interface 52 after a malfunction in the 
PFM system 12. During a malfunction, the handler 31 
normally deletes this queue when it is stopped. 

Another type code of "M" is used to perform updates 
related to the mover 32. An action code of "S*' is used to 
manually start the mover 32 instead of waiting for the 
handler 31 to start it based on normal TCUy intervals. When 
requested, a CICS START command for the mover 32 is 
executed. An action code of "P" for stop is used to manually 
stop the mover 32. This slop of the mover 32, as stated 
above, cannot occur until all records for a given batch are 
processed due to its handling of batch control totals. Thus, 
if the stop action code is entered, the mover 32 will show a 
status of "QUIESCING" until the batch is complete, at 
which time it will stop. An action code for times "T*' is used 
to dynamically change the start and stop times of the mover 
32, thereby overriding the values loaded from the calendar 
record stored on the security file 47. An inquiry update 
having an action code of "1" is used to show the status of the 
mover 32. 

The router 33 can also be updated through the input/ 
output device 71 with a type code of "R." An action code of 
"S" is used to manually start the routers 33 instead of 
waiting for the handler 31 to start them. When requested, the 
CICS START command for the routers 33 will be executed 
based on the router control variables found in the temporary 
storage queue in the handler mover control interface file 52. 
A stop update, having action code "P," is used to manually 
stop the routers 33. When requested through the device 71, 
no additional routers 33 may be started by the handler 31 
until after the current routers 33 finish their tasks. An inquiry 
as to the status of the routers 33 may be made through an 
action code of "1." 

Other updates are included under a type code "F" for file 
requests and a type code "P' for transaction requests. Under 
the type code "F," an action code of "I" is used to show the 
status of the temporary transaction queues 39, 40, and 42 
input to the mover 32. Under the type code "T," an action 
code of is used to dynamically allow transactions to be sent 
to the routers 33 that were bypassed either dynamically or 
due to the handler record defaults stored on the security file 
47. Also under type code "T," an action code "P' for stop is 
used to dynamically keep u-ansactions firom being sent to the 
routers 33 in case of a system malfunction. 

The input/output device 72 provides a communications 
interface between a transaction handler message device 54 
and the U-ansaction mover queue update device 55. The 
transaction handler message device 54 displays on the 
device 72 any errors encountered during processing, such as 
in the handler 31, mover 32, router 33, or driver 34. Any 
errors are stored on the router mover error file 53 and 
displayed starting at the beginning of the file. The errors are 
reported and deleted fi-om the file during nightly batch 
processing. The Uansaction mover queue update device 55 
maintains mover queue records stored on the router mover 
error file 53. As discussed above, the mover queue records 
are used to determine the order in which temporary queue 
files will be processed as inputs to the mover 32. The records 
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are also used to keep track of the RBA for the last record 
processed by the mover 32. Through the transaction mover 
queue update device 55, records are maintained for the input 
queue name, priority for a queue, record length, key length, 
the RBA for the last record information, the program name 5 
required for any special processing of the transaction, such 
as the cash loader 62, and the output queue. 

A memo file inquiry device 67 provides displays of any 
CAT payments that have been posted to the memo post file lo 
68 by the CAT payment driver 34d. Since the master files 58 
are read-only in CICS during batch processing, any updates 
resulting from CAT payments are memo posted by the CAT 
driver 34d to allow the customer to see the results of their 
payments immediately. When the handler 31 and subse- is 
quently the payment driver 34a are activated, the payments 
in the memo post file 68 will be permanently posted to the 
master files 58 and deleted from the memo post file 68. Until 
the time that the payment driver 34a performs this perma- 
nent update, the memo file inquiry device 67 may be used to 
view any CAT payments that have been made since the last 
update of the master files 58. The inquiry device 67 will start 
at the beginning of the file unless an account is entere^d to 
start the search at a specific point. A series of four records 
will exist for each account that was memo posted based on 
the DLS master file 58 that was updated. 

In the preferred embodiment, the handler 31, mover 32, 
router 33, drivers 34, monitor 35, and various other com- 
ponents of the PFM system 12 comprise on-line CICS 30 
programs operated on a mainframe computer. Since the 
generation of programs for the various elements of the PFM 
system 12 will be apparent to one of ordinary skill in the art, 
further details of the programs have been omitted in order lo 
simplify the description of the invention. While the inveo- 35 
tion is preferably implemented on a single mainframe 
computer, it should be understood that the invention can be 
implemented with more than one processor. Other variations 
to the invention will be apparent to those skilled in the art. 

40 

In summary, the PFM system 12 permits the on-line 
processing of transactions received from various sources, 
such as lock-box facilities 17, a CAT 13, an enhanced 
telephone 15, or a personal computer 16. Consequently, 
delays between depositing payments and the actual posting 
of the payment to the master files 58 have been significantly 
reduced. For instance, instead of a delay of twenty four or 
more hours with a conventional processing system, the 
processing system 10 according to the invention is easily 
capable of updating the master files 58 within hours. The 
monitor 35 in the system 12 provides continuous speed 
control thereby preventing the PFM system 12 from pre- 
senting unacceptable delays to the normal users 18 of the 
system 12. With the monitor 35, the system 12 is able to 
sense and react very quickly to any change in environment 
conditions, such as either an increase or decrease in the 
demand from the normal on-line users 18. The system 12 
also presents a hierarchical treatment of transactions 
whereby the more urgent transactions are processed before 
other less urgent transactions. ^ 

It should be recognized that the system and method 
disclosed are merely illustrative of the principles of the 
present invention. Numerous modifications and adaptations 
thereof will be readily apparent to those skilled in the art 
without departing from the spirit and scope of the present 65 
invention. Accordingly, the invention is only limited by the 
following claims. 
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What is claimed is: 

1. A transaction processing system comprising: 
a central processing facility; 

a receiving facility for receiving payments to individual 
accounts and for generating batch payment data based 
on the payments; 
a central processing facility comprising; 

a batch converter for receiving said batch payment data 
from said receiving facility and for converting said 
batch payment data into payment transaction data for 
the individual accounts; 
a transaction handler; 

a transaction mover that transfers transaction data from 
temporary storage queue files to a transaction queue; 

a plurahly of payment drivers; 

a plurality of transaction routers that determine to 
which drivers to assign the transaction data; 

said payment drivers receiving said transaction data 
and updating a set of account master data files to 
reflect said payments; and 

a transaction monitor for tracking a time of completion 
for each payment driver and for writing said permis- 
sible number of drivers to a temporary storage 
queue; 

wherein said transaction monitor further determines the 
maximum number of said routers and said drivers 
based on said completion times, thereby providing 
variable processing speed control to the system; 

wherein said handler determines when transaction data 
is available for processing and assigns transaction 
data to said routers; and 

wherein said transaction handler reads said temporary 
storage queue and limits the number of routers which 
are active based on said permissible number of 
drivers specified in said temporary storage queue. 

2. The processing system as set forth in claim 1, wherein 
said receiving facility comprises a lock-box facility and said 
receiving means comprises scanning equipment for captur- 
ing said transaction data from payment coupons and checks. 

3. The processing system as set forth in claim 1, wherein 
said receiving facility comprises a home services dehvery 
system and said receiving means obtains said transaction 
data from an enhanced telephone. 

4. The processing system as set forth in claim 1, wherein 
said receiving facility comprises a home services delivery 
system and said receiving means obtains said transaction 
data from a personal computer. 

5. The processing system as set forth in claim 1, wherein 
said receiving facility comprises an automated teller 
machine and said receiving means obtains said transaction 
data from customer inputs to the automated teller machine. 

6. The processing system as set forth in claim 1, wherein 
said batch converter stores said payment transaction data on 
a temporary storage queue, 

7. The processing system as set forth in claim 1, wherein 
said transaction handler transfers said transaction data from 
said transaction queue to an available router. 

8. The processing system as set forth in claim 1, wherein 
said routers store completion limes for their respective 
drivers in a slots intervals file and said monitor receives said 
completion times from said slots intervals file and deter- 
mines an average completion time for all of said drivers. 

9. The processing system as set forth in claim 1, wherein 
said handler activates said mover at regular intervals of time. 

10. The processing system as set forth in claim 1, wherein 
said monitor determines said permissible number of drivers 
at regular intervals of time. 
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11. The processing system as set forth in claim 10, 19. The method asset forth in claim 16, wherein said step 
wherein said regular intervals of time comprises every 20 of receiving comprises the step of receiving payments from 
milliseconds. an automated teller machine. 

12. The processing system as set forth in claim 10, 20. The method as set forth in claim 16, wherein said step 
wherein said monitor prevents the number of permissible 5 of receiving comprises the step of receiving payments from 
drivers from exceeding a maximiun oiunber of drivers. a lock-box facility. 

13. The processing system as set forth in claim 1. wherein 21. The method as set forth in claim 16, wherein said step 
said routers assign transaction data representing a plurality receiving comprises the step of receiving payments from 
of payments to each payment driver. .an enhanced telephone. 

14 The processing system as set forth in clami 1, wherein lO ^2. TTie method as set forth in claim 16, wherein said step 

said handler classifies said paynaent transaction data mto a comprises the step of receiving payments from 

plurahty of prionty groups, said handler transferrmg said i 

r I . * • .1. • : ' J c a personal computer, 

transaction data to routers m the pnonty groups m order of r„ . , ^t-,.*^. 

priority begmning with a highest priority group so that said ^3. The method as set forth in claim 16, wherein said step 
drivers updTTe said master files based on said transactions in 15 -^on-fon-g composes a step of determinmg an average 

said highest priority group before transactions in any other «'°P'!?°° ^^"^ 1°' said dnvers. 

. ^ =^ ^ 24. The method as set forth m claim 16, wherein said step 

''"is! TheTrocessing system as set forth in claim 1, wherein monitoring is repeated at regular intervals so that a speed 

said central processing facUity further comprises means for P'°^^"'8 PaJ^ents is conUnuously momtoied. 

providing access to said master files for at least one account 20 The processmg system as set forth m claim 1 wherein 

service provider while at least one of said driveis is active. speed control mmmiizes the consumpuon of system 

i£ A .r.^' r. ^ resources due to the processmg of said payment transaction 

16. A method tor processmg transactions compnsmg: , , . , . , 

. r ^ ^^j^ relative to other on-hne processes thereby permitting 

receiving payments and generating batch payment data at simultaneous payment processing and on-line account ser- 

a receiving facihty; ^-^^^ processing, 

transferring said batch payment data to a central facility 26. llie method as set forth in claim 16 further wherein 

and converting said batch payment data to transaction the consumption of system resources due to the processing 

flata; Qf said payment transaction data relative to other on-line 

moving said transaction data from temporary storage processes is minimized. 

queue files to a temporary queue; method as set forth in claim 16 further wherein 

determining to which individual payment drivers to payment processing and on-line account services processing 

assign said transaction data on said temporary queue; occur simultaneously, 

assigning said transaction data to transaction routers; '^'^ processing system as set forth in claim 1 wherein 

, ^ . .J said payments compnse financmg payments, 

updatmg mdividual account mformation m said master ^9. The processing system as set forth in claim 28 wherein 

files with said payment dnvers based on payments ^5 ^^.^ ^^^^ payments comprise mortgage payments. 

refiecled in said payment transaction data; 3^ processing system as set forth in claim 28 wherein 

monitoring a completion time for each payment driver; said financing payments comprise automobile and mobile 

providing variable processing speed control to the home payments. 

system by controUing the number of drivers and routers 31 . The processing system as set forth in claim 28 wherein 

which are permitted to be active based on the comple- said financing payments comprise student loan payments, 

tion times for the payment drivers; and 32. ^nie method as set forth in claim 16 wherein said 

determining when said transaction data is available for payments comprise financing payments. 

processing. 33. 'ITie method as set forth in claim 32 wherein said 

17. The method as set forth in claim 16, further including financing payments comprise mortgage payments. 

a step of providing access to said master files to service 34. The method as set forth in claim 32 wherein said 

providers for the individual accounts. financing payments comprise automobile and mobile home 

18. The method as set forth in claim 16, further including payments. 

a step of classifying said transaction data into priority groups 35. The method as set forth in claim 32 wherein said 

and performing said updating step in order of priority financing payments comprise student loan payments, 
beginning with a group of transaction data in a highest 

priority. ♦ * * * ♦ 
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